17.12 Sitzungsverfolgung (Session Tracking) 

Im vorigen Kapitel haben wir uns mit dem Problem beschäftigt, wie trotz des zustandslosen Protokolls ein Verlauf auf dem Server verwaltet werden kann. Wir haben dafür die kleinen Informationseinheiten der Cookies eingesetzt, doch gibt es andere Lösungen, die wir noch einmal mit all ihren Vor- und Nachteilen zusammenfassen:

• Cookies. Ein Cookie speichert eine Kennung, sodass der Server den Client erkennt und die Informationen für ihn speziell aufbereitet. Obwohl dies in Java durch die Cookie-Klasse einfach möglich ist, hat dieser Ansatz noch einige Schwächen. Dem Servlet fällt die Aufgabe zu, aus der Cookie-Kennung die entsprechende Sitzung herauszusuchen und die Daten zu holen. Ein weiteres Problem ergibt sich dadurch, dass Cookies zwar möglich sind, aber vom Benutzer abgelehnt werden können, da dieser seine Anonymität aufs Spiel gesetzt sieht. Schaltet der Benutzer in seinem Lieblingsbrowser die Cookies aus, können wir nichts machen. Doch auch wenn Cookies verwendet werden, bleibt die Frage, wie lange der Cookie gültig sein soll. Hier ist zu überlegen, ob die Voreinstellung, dass »der Keks« nur eine Sitzung übersteht, sinnvoll ist.

• URL-Rewriting. Da ein Servlet vom Aufrufer Parameter bekommen kann, ist es eine nette Idee, an die URL einen Wert anzuhängen, der die aktuelle Sitzung kennzeichnet. Diese Kennung entspricht dann genau dem Wert des Cookies. Die Lösung ist simpel und funktioniert bei allen Browsern. Der Nachteil auf der Serverseite ist wiederum, dass uns die Aufgabe zufällt, der Kennung die Sitzung zuzuordnen. Zudem ist Vorsicht geboten, da diese Kennung bei jedem Verweis wieder angehängt wird. Außerdem ist es für den Benutzer sehr unschön, diese Kennungen zu sehen, zumal sie in die Bookmarks übernommen werden. Dies führt zu dem Problem, dass eine Sitzung angesprochen werden kann, die gar nicht mehr existiert. Dies ist ein sehr schwer wiegendes Problem, da die Anhängsel ja nicht wie Cookies automatisch veralten.

• Versteckte Felder (engl. hidden fields). In HTML-Seiten lassen sich versteckte Informationen in Formularen anlegen, die beim Versenden automatisch mitgeschickt werden. Dies sieht etwa so aus:

   <INPUT TYPE="HIDDEN" NAME="session" VALUE="...">

Diese versteckten Informationen können auch genutzt werden, um eine Sitzungs-ID mitzuschicken. Der Vorteil ist, dass wir wieder keine Cookies benötigen und die URL nicht länger wird, der Nachteil, dass die Information immer dynamisch mit eingebaut werden muss.

Cookies erlauben dem Server, den Client wiederzuerkennen und ihn einer Sitzung zuzuordnen, doch haben wir gesehen, dass unser Servletcode noch einiges an Arbeit investieren muss. Der Cookie musste gesetzt und geholt werden, und wir mussten die Daten in einer Datenstruktur verwalten. Wenn der Benutzer Cookies ablehnt, müssen wir eine zweite Implementierung anbieten, die Sitzungsinformationen an die URL anhängt.

Glücklicherweise entlastet uns die Servlet-API und bietet die Klasse HttpSession an, eine Bibliothek auf hohem Niveau für die Verwaltung einer Sitzung. Sie basiert entweder auf Cookies oder URL-Rewriting, doch wird das von der API transparent gehalten. Als Programmierer bekommen wir so gut wie gar nichts davon mit. Falls der Client keine Kekse mag, wandeln wir alle Informationen in URLs um, die wir dann anbieten. Ein Sitzungsobjekt verwaltet die gesicherten Daten auch selbstständig in einer Datenstruktur. Hier fällt für uns keine Arbeit an.

17.12.1 Das mit einer Sitzung verbundene Objekt HttpSession 

Jede Sitzung ist mit einem Sitzungsobjekt verbunden, das die Klasse HttpSession abbildet. Bei JSPs repräsentiert das implizite Objekt session die aktuelle Sitzung.

17.12.2 Werte mit einer Sitzung assoziieren und auslesen 

Um Informationen mit der Sitzung zu verbinden, verwenden wir die Methode setAttribute(), die einen Schlüssel und einen Wert verbindet. Daten werden mit getAttribute() wieder aus der Datenstruktur gelockt, so wie es das folgende Beispiel zeigt:

List l = (List) session.getAttribute( "artikel" );

Hier verbinden wir mit einem Schlüssel eine Liste von Waren. Im Hintergrund werden die Informationen auf der Serverseite gesichert. Die Informationen selbst werden nicht in Cookies oder in der URL abgelegt, daher spielt die Größe der Daten auch keine Rolle. Ein HttpSession-Objekt verwaltet einen Assoziativspeicher, der die Wertepaare speichert. Es ist günstig, die Elemente serialisierbar zu gestalten, um die Daten dauerhaft zu speichern.

Werfen wir abschließend einen Blick auf das Programmstück, das eine neue Ware hinzufügt:

List l = (List) session.getAttribute( "artikel" ); 
if ( l == null ) 
{ 
  l = new ArrayList(); 
  session.setAttribute( "artikel", l ); 
} 
l.add( w );

interface javax.servlet.http.HttpSession

• Object getAttribute( String name ) Liefert das mit name verbundene Objekt; null, wenn es keine Assoziation gab.

• Enumeration getAttributeNames() Liefert eine Aufzählung aller mit der Sitzung verbundenen Objekte.

• void setAttribute( String name, Object value ) Bindet name mit dem Objekt value an die Sitzung. Existierte das Objekt, wird es ersetzt. Angemeldete HttpSessionBindingListener werden über die Methode value Bound() beziehungsweise valueUnbound() informiert.

• void removeAttribute( String name ) Entfernt das Attribut von der Sitzung. Ungültige Namen werden ignoriert. HttpSession BindingListener werden durch Aufruf von valueUnbound() informiert.

Alle Methoden liefern eine IllegalStateException, wenn die Sitzung ungültig ist. Die Methoden putValue() und setValue() sind veraltet und wurden durch setAttribute() und getAttribute() ersetzt.

17.12.3 URL-Rewriting 

Das Session-Management sollte im Prinzip unabhängig von der technischen Umsetzung sein. Doch leider greift das Sitzungsmanagement beim URL-Rewriting schon sehr stark ein: Bei jedem Verweis auf eine neue Seite muss die URL entsprechend angepasst werden, weil die Sitzungs-ID mitgeschickt werden muss. Cookies verwalten die Sitzungs-ID völlig anders. Das bedeutet: Werden Cookies eingesetzt, ändert sich die URL nicht und jeder kann problemlos auf eine neue Seite verweisen. Nur beim URL-Rewriting muss an die URL eine Sitzungskennung angehängt werden.

Wenn wir innerhalb eines Servlets auf eine andere generierte Seite verweisen wollen, haben wir eine URL vor uns, zu der wir verzweigen möchten. Die Servlet-API kümmert sich darum, an eine Benutzer-URL die Sitzungs-ID automatisch anzuhängen. Dazu dienen die HttpServletResponse-Methoden encodeURL() und encodeRedirectURL().

<form action='<%= response.encodeURL("/validate.jsp") %>'>

Werden der Verweis und die Kodierung aus Versehen vergessen, ist dies das Ende der Sitzung. Ob eine Sitzung mit einem Cookie behandelt wird, lässt sich mit isRequestedSession-IdFromCookie() testen. Dann kann aufgrund einer Fallunterscheidung encodeURL() verwendet werden oder nicht. Allgemein ist es aber nicht schlecht, grundsätzlich alle Verweise innerhalb einer Webapplikation mit encodeURL() zu sichern. Im Fall von Cookies wird zwar keine Kennung angehängt, eine spätere Umstellung gestaltet sich aber einfacher, falls der Nutzer die Cookies einmal ausschaltet.

17.12.4 Zusätzliche Informationen 

Ein Sitzungsobjekt verwaltet neben den assoziierten Daten noch weitere Informationen. Jede Sitzung bekommt eine eindeutige ID, die sich mit getId() erfragen lässt. Ist die Sitzung neu und hat der Client noch nie eine Verbindung gehabt, gibt isNew() den Wert true zurück. Existiert dann die Sitzung, gibt getCreationTime() ein long zurück – kodiert sind wie üblich die vergangenen Millisekunden seit dem 1.1.1970 –, in dem sich das Erstellungsdatum erfragen lässt. Dagegen erfragt getLastAccessedTime() die Zeit, die seit dem letzten Zugriff durch den Client vergangen ist. Falls der Server die Informationen dauerhaft speichert und der Cookie nicht abläuft, erlaubt dies Meldungen der Art: »Schön, Sie nach zwei Wochen zum fünften Mal bei unserer Partnervermittlung wiederzusehen. Hat's wieder nicht geklappt?«

Das Ende der Sitzung

Eine Sitzung ist nicht automatisch unendlich lange gültig. Bei Cookies lässt sich der Gültigkeitszeitraum einstellen. Auch Sitzungsobjekte lassen sich in der Zeit anpassen. Die Methode setMaxInactiveInterval() setzt den Wert, wie lange eine Sitzung gültig ist. Ist der Wert negativ, zeigt er an, dass die Sitzung nicht automatisch beendet wird. Die entsprechende Methode getMaxInactiveInterval() liefert die Zeit in Sekunden, in der eine Sitzung gültig ist.

interface javax.servlet.http.HttpSession

• long getCreationTime() Gibt in Millisekunden ab dem 1.1.1970 an, wann die Sitzung eröffnet wurde.

• String getId() Liefert eine eindeutige Kennung, die die Sitzung identifiziert.

• long getLastAccessedTime() Gibt in Millisekunden ab dem 1.1.1970 zurück, wann der Client zum letzten Mal auf den Server zugegriffen hat.

• int getMaxInactiveInterval()

• void setMaxInactiveInterval( int interval ) Liefert und setzt die Zeit, für die der Servlet-Container die Sitzung aufrechterhalten soll, bis sie ungültig wird.

• boolean isNew() Der Rückgabewert ist true, wenn die Sitzung neu ist.

Listing 17.19    sessionTracking.jsp

<%@ page language="java" import="java.util.*" %> 
<% 
  int cnt = 0; 
  if ( session.isNew() ) 
  { 
    out.println( "Willkommen Neuling!\n" ); 
  } 
  else 
  { 
    out.println( "Hallo, alter Freund!\n" ); 
    String o = (String) session.getAttribute( "cnt" ); 
    if ( o != null ) 
      cnt = Integer.parseInt( o ); 
    cnt++; 
  } 
  session.setAttribute( "cnt", ""+cnt ); 
%> 
 <p> 
 Session-ID: <%= session.getId() %> <p> 
 Erzeugt am: <%= new Date(session.getCreationTime()) %> <p> 
 Letzter Zugriff: <%= new Date(session.getLastAccessedTime()) %> <p> 
 Ungültig in Minuten: <%= session.getMaxInactiveInterval()/60%> <p> 
 Anzahl Zugriffe: <%= cnt %>

Das Programm liefert beispielsweise folgende Ausgabe:

Hallo, alter Freund! 
ID: 91410050092487D9B5D0D2A7A3D0F072 
Erzeugt am: Fri Jan 18 20:16:49 CET 2002 
Letzter Zugriff: Fri Jan 18 20:23:33 CET 2002 
Ungültig in Minuten: 30 
Anzahl Zugriffe: 4

Die ID sieht bei jedem Server anders aus. Der Webserver von Sun erzeugt beispielsweise ganz andere Kennungen.